Conventional network communications are typically transmitted from a sender to a single receiver. This mode of point-to-point network communication is often referred to as “unicast.” Reliable data delivery in the unicast mode across an unreliable network, such as the Internet, is conventionally achieved through an end-to-end transport protocol, such as the TCP, in which the sender implicitly or explicitly solicits receipt information from the receiver. In the unicast mode, even though multiple clients on the network may request the same data from the sender at the same time, duplicate data streams are transmitted, one to each client.
In contrast, in a “multicast” transmission, a sender sends a message to multiple recipients at the same time. One of the most important advantages of multicast over unicast is that multicast conserves bandwidth of the sender and the network by sending a single stream of data to a group multicast address. This advantage is especially important for applications such as multiparty conferencing or broadcasting live multimedia events over the network, where the bandwidth requirements can be significant. Although multicasting is not a new concept, network communications in the multicast mode over computer networks, especially the Internet, have only recently become common. This is partly due to that today's networks are originally designed to reliably transmit data from point to point, i.e., in the unicast mode, and multicast operations require the establishment of effective protocols for handling the delivery of multicast packets and the implementation of the required network infrastructure to support the multicast transmissions.
A major consideration in designing a multicast framework is the reliability of the delivery of multicast packets over an unreliable network to a potentially large group of receivers, the group membership of which may not even be known to the sender. To achieve reliable multicast delivery, loss detection and recovery must be properly handled. Various frameworks have been proposed to address the issue of reliable delivery of multicast data. See, e.g., Sally Floyd, Van Jacobson, Ching-Gung Liu, Steven McCanne, and Lixia Zhang, “A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing,” IEEE/ACM Transactions On Networking, December 1997.
In one implementation based on the Pragmatic General Multicast (PGM) protocol, which is described in an IETF draft entitled “PGM Reliable Transport Protocol Specification,” each receiver in the multicast group takes the responsibility for loss detection and recovery. According to the PGM protocol, a source or sender multicasts sequentially numbered data packets, which are called “original data” (ODATA). The sequential numbering of the ODATA packets enables a multicast receiver to determine whether any packet is lost in transit. In contrast to the conventional unicast scheme that requires “positive” acknowledgments for received packets, the receiver in the PGM network sends to the source “negative” acknowledgments (NAKs) identifying packets detected to be missing from the expected sequence. When the sender receives an NAK, it first multicasts an “NAK confirmation” {NCF} packet and then multicasts the data identified in the NAK in repair data (RDATA) packets. After receiving the NCF, the receiver waits for the RDATA. The RDATA, of course, may also be lost in transit. If after a while the RDATA is still not received, the receiver repeats its attempt to get the lost data by sending the NAK again.
The timing for the sender to send out the RDATA and the timing for the receiver to resend the NAK can greatly impact the efficiency and effectiveness of this scheme for reliable multicast delivery. The PGM protocol, however, does not explicitly define such timing requirements. Accordingly, there is a need for a way for use in a reliable multicast scheme based on the PGM protocol or similar protocols to set time parameters for a sender to send RDATA packets and for a receiver to resend NAKs.